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1. Abstract 

A general purpose six-axis robotic manipulator controller was designed and Implemented to 
serve as a research tool for the Investigation of the practical and theoretical aspects of 
various control strategies In robotics. A 803.36-based Intel System 310 running the Xenix 
operating servo software as well as the higher level software (e.g. kinematics and path 
planning). A Multibus compatible Interface board was designed and constructed to handle I/O 
signals from the robot manipulator’s joint motors. 


From the design point of view, the universal controller Is capable of driving robot 
manipulators equipped with D.C. joint motors and position optical encoders. To test Its 
functionality, the controller Is connected to the joint motor D.C. power amplifier of a PUMA 
560 arm bypassing completely the manufacturer-supplied Unlmatlon controller. A controller 
algorithm consisting of local PD control laws was written and Installed Into the Xenix 
operating system. Additional software drivers were Implemented to allow application programs 
access to the Interface board. All software was written In the C language. 


2. Introduction j- 

Robots are becoming increasingly prevalent in the industrial workplace, as well as creating an industry of 
their own. This new industry is both driving and being driven by new technologies. New materials, improved 
mechanical designs, and faster controller electronics ane running into the limitations of traditional control 
techniques. Thus, theoretical work to overcome these /imitations is urgently needed. Much of the theoretical 
work is being carried out In academic research institutions. However, there is often a significant gap between 
the results of theoretical studies based on simulations and the verification based on actual Implementation. 
Industry Is often reticent to try untested theoretical results, preferring the time-tested, sub-optimal control 
techniques of the past, possibly sacrificing substantial performance Improvements. A credible testing ground 
for new control techniques Is needed to brldg^ the gap between theory and application. 

The Robotics Research Laboratory at the University of California, Davis, has a Unlmatlon PUMA 560 robot arm 
representative of a large and popular class of modern Industrial manipulators. The PUMA arm is controlled 
tnrouqh the sophisticated robot language, VAL-II. The user only has access to the arm through high level 
•move-type* conmands. He therefore little control of the actual arm trajectory and no control over the low 
level motor servo loops. In typical Industrial applications, the Inability to alter low level functions of the 
controller does not represent a functional limitation. To the contrary. It actually affords both the arm and 
the operator a fair degree of protection and safety. The academic researcher, however, is prevented from using 
the arm to test and demonstrate new control strategies and Is forced to rely on computer simulation. 


3. Objective < 

The objective of this project was to design and Implement a ctmputer based robotic controller which allows 
the researcher to write programs and Implement algorithms which control the robot arm from the lowest level of 
the closed-loop servo system to the higher levels of kinematics, dynamics, path planning and robot language 
[II]. The use of a familiar software environment was chosen with the Intent of making the user Interface as 
clean and simple as possible. 

The scope of this project Is limited to the design and implementation of a controller consisting of (1) the 
Joint Interface Board electronics, and (2) the operating system Interface to this hardware. A simple low level 
6-jolnt P.I.D. (Proportional Integral Derivative) controller Is Implemented and presented to serve as both a 
functional test "of the system and as an application example. The topics of joint kinematics and other high 
level application software are beyond the scope of this project as is the advanced control law design. 
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4. The Controller System 


The controller presented here Is designed around an Intel 310 , 80286-based, microcomputer [2] running the 
UNIX-like operating system, XENIX [3], A signal Interface board was designed and constructed to provide the 
interface between the microcomputer and the joint motors of the arm. The Unlmatlon controller, supplied as part 
of the PUMA 560, was modified to serve two low level functions: as a convenient access point for the joint 

feedback signals from the arm and as a multi-channel power amplifier drive the joint motors. All other 
electronics In the Unlmatlon multi-channel power amplifier to drive the joint motors. All other electronics In 
the Unlmatlon controller are by-passed; closed-loop control Is done In the Intel-based controller described 
here. The controller system Is depicted by the block diagram shown In Figure 1. 

A single 80286 CPU running at 6 MHz Is used to execute both high level (e.g. kinematics) and low level 
(e.g. joint servo loops) control software. At a typical sampling rate of 100 Hz, about 30% of the CPU time Is 
required to execute the six P.I.D. controllers Implemented In the design example. The remaining CPU time Is 
available for application programs and the operating system. The Interface board Itself Is useful In systems 
with sampling rates over 2 KHz. However, to utilize this speed, additional CPU power Is required. 


5. System Design Requl rements 

Two basic elements constitute the controller system designed and Implemented In this project: a digital 

computer and special purpose Interface hardware. The digital computer performs all the control functions, from 
the joint motor servo control law to the higher levels of coordinated joint motion. The 1-terface hardware 
function Is to provide the basic link between the computer and the physical signals required to control the 
robot arm. 

5.1 The D.C. Servo Motor Position Measurement 


The control of the robot arm is equlvalant to the control of the joint motors. In this controller, D.C. 
servo motors are assailed to be equipped with potentiometer and/or Incremental encoder position feedback devices. 
It Is also assumed that the D.C. motor can be driven by an analog {voltage) signal buffered by an appropriate 
external power amplifier {servo motor amplifier). The Unlmatlon PUMA 560 arm has six geared D.C. servo motors 
with both encoder and potentlomenter position feedback elements and It Is considered to be prototypical of the 
class of manipulators considered In this project. 

Each motor, in general, does not directly drive a manipulator joint, but Is typically connected through a 
gear train requiring a multiple number of motor revolutions to drive the joint through Its operating range as 
shown In Figure 2. In the configuration assumed In this project, feedback elements are directly attached to 
the motor, not the actual joint member. Joint position Is Inferred from the motor position. This requires that 
absolute motor position must be measured over multiple revolutions. In the PUMA arm, both a geared (i.e. multi- 
turn) potentiometer and an incremental shaft encoder are connected to the motor shaft to co’iectlvely supply 
this data. The Incremental encoder is used to accurately measure both the relative motor position over an 
arbitrary number of rotations and the absolute motor position modulo one rotation. The geared potentiometer 
Is used to measure the approximate absolute motor angle over the several revolutions needed to drive the joint 
through Its range. Once the absolute motor angle has been determined, only the relative data supplied by the 
encoder Is needed. 

The Incremental encoder, which is directly attached to the motor, generates two types of data: (1) high 

resolution quadrature signals which are decoded into relative (incremental) angular displacement information and 
(2) an index pulse which is produced once per revolution and can be used to accurately define the absolute 
angular position of the motor modulo 360° (Figure 2). 

The geared potentiometer supplies Indirect, low resolution absolute joint position data. The gear ratio of 
the potentiometer is designed so that when the joint is driven between its mechanical limits, the pot wiper 
rotates within its mechanical limits (less than 360°). Logically, this pot could have been attached directly to 
the robot joint. For manufacturabl 1 i ty considerations, the pot has been included in the motor assembly. 

Once the absolute motor position has been determined, it is continuously updated (incremented or decre- 
mented) by the data frcm the incremental shaft encoders. As long as the electronics are not interrupted (e.g. 
power-down) the data from both the geared pot and the encoder's index pulse are not used. The difficulty is the 
initial determination of the absolute motor position is rather involved and will now be discussed. 

When the absolute motor position is unknown, the potentiometer wiper voltage can be measured and the 
aDsolute motor position estimated. Once estimated, further position measurement can be made by monitoring the 
relative position data from the incremental encoders. While the incremental data is very accurate, the absolute 
position can only be as good as the initial estimate. The standard technique to obtain an accurate measurement 
of the initial absolute position is as follows. First, the motor is driven until the encoder's index pulse is 
found. At this point the absolute position is known to be an exact multiple of 360°. Next, the potentiometer- 
voltage is measured to give the approximate absolute position. Combining the approximate absolute position with 
the certain knowledge that the position is an exact multiple of 360°, the exact absolute can then be derived. 

The above explanation serves to demonstrate the basic idea and what sort of precision is required. For 
analysis, the actual parameters of the PUMA 560 joint motors are used to determine the system specifications and 
Joint Interface Board requirements. 
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5.2 A Typical D.C. Servo Motor 

The PUMA 560 servo motors are Integral packages which contain four basic components: (1) a D.C. motor; 

(2) an electric brake; (3) an optical Incremental encoder; and (4) a geared-down potentiometer. The currents 
activating the motor and the electric brake are the Inputs while the encoder and the potentiometer signals are 
the outputs. The basic functions needed to operate the motor system are described below. 

5.2.1 Reading the Incremental Encoder 

The Incremental encoder has three output signals: channels A, B, and the Index pulse. Channels A and B 

are used to determine both the anount and direction of rotation In discrete steps. The Index pulse produces a 
single short pulse each motor revolution which can be used by the system to determine the absolute angle of the 
motor and, with the addition of the potentiometer data, can be used to determine absolute position (described 
above) . 

The output states of channels A and B are used to detect relative motion (rotation) of the motor shaft and 
In turn, the joint Itself. How this Is done Is well-known and Is not described here. 

5.2.2 Counting the State Changes 

The Incremental encoders on the PUMA 560's motors produces 1000 state transitions per revolution, except 
for the shoulder joint (#2) which produces 800 transitions. The motor (with the encoder directly attached) 
rotates from 40 to 60 times during full joint travel (depending on the joint), corresponding to 40,000 to 60,000 
state changes per complete joint motion. It Is convenient If the hardware keeps count of the total Joint range. 
This way the total joint motion may be read directly from the hardware counters. 16-bit counters have a maximum 
count of 65,532 and are sufficient to keep track of the joint motors of the PUMA arm. However, it Is not 
essential for the hardware to count the entire joint range. In a sampled data system, the software can keep 
track of total Joint motion, using the hardware only to count the relative motion which has occurred between 
samples. If the hardware count is used in this manner, the absolute motion Is limited only by software and the 
Incremental motion between samples Is limited to motion of * 32K pulses. 

5.2.3 Reading the Potentiometers 

The potentiometers incorporated Into the PUMA 560 joint motors are connected between +5 volts and ground. 
Rotating the pot through 360° produces a proportional voltage output from 0 to 5 volts (e.g., 90 produces 1.25 
volts, 180° produces 2.5 volts, etc.). These pots have been geared so that they rotate somewhat less^than 360 
for a complete joint movement; depending on the joint, full joint travel may produce as little as 200 of 
potentiometer motion. This restricted travel corresponds to a change In pot voltage of about 2.78 volts. If 
the joint produces 60 index pulses (l.e. 60 motor rotations) per full joint motion, the pot voltage must be 
measured to an absolute accuracy of 1/60 th of 2.78 volts (0.046 volts) In order to determine the motor shaft 
angle to within one revolution. 

An Analog to Digital Converter (ADC) is used to measure the pot voltages. It must be able to measure a 
voltage which spans a 0 to 5 volt range, and must have a resolution and accuracy of better than 0.046 volts over 
this range. This corresponds to a full-scale resolution of 0.92%. A seven-bit ADC has a resolution of 0.78% 
and Is sufficient for this voltage measurement. 

Since the potentiometers are not part of the dynamic control scheme presented here, there is no constraint 
on the conversion speed. For the PUMA arm, both speed and resolution requirements of the ADC are easy to meet. 
However, to make the system more flexible, other possible applications should be considered. It is often the 
case where a symmetrical voltage signal (say -5 to +5 volts) needs to be measured and fast conversion time can 
make dynamic control systems with analog feedback elements possible. Furthermore, since fast (30 microsecond) 
12-bit ADCs with input range of t5 volts are conveniently available and at reasonable cost, this higher 
performance device was chosen. 

5.2.4 Drl vl ng the Motor 

The drive current and voltage needed by a D.C. motor depends on the size and type of motor used; no 
solution is appropriate for all motors. It is therefore considered Impractical to include the power amplifier 
as part of the design. The important requirement is how to drive these power amplifiers. 

In general, two standard techniques for supplying the current needed for driving D.C. servomotors are 
commonly used: linear amplifiers and pulse width modulated (PWM) amplifiers. Each have advantages but the 

Important fact tc consider Is that they both are controlled by a simple analog voltage. 

In the particular case of the PUMA 560 arm, the Unlmatlon PUMA controller's power amplifiers can be 
conveniently used because they have been designed explicitly to drive the PUMA 560 joint motors. Using this 
controller also makes the external connection to the arm joint motors simple and straightforward. Additionally, 
the Unlmation amplifier has several useful safeguards which automatically shut the amplifier off to prevent 
damage to the arm. 

Power amplifiers are controlled by analog voltages, and to generate these voltage outputs from a digital 
controller a Digital to Analog Converter (DAC } must be used. Three basic specifications must be considered: 

(1) voltage swing; (2) resolution (number of bits); and (3) the accuracy. Commercially available power 
amplifiers typically require a voltage input of -10 volts to +10 volts. This also corresponds to typical DAC 
device output characteristics, and the input specifications of the Unlmatlon controller's power amplifier. 
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Selection of resolution and accuracy Is more difficult. 8-bl t corresponds to a resolution of one part In 256 
(0.391) , 10-bit corresponds to one part In 1024 (0.0981), and 12-bit corresponds to one part In 4096 (0.0241). 

A 10-bit unit was chosen and considered to be a reasonable compromise between price and performance. 

5.2.5 Releasing the Brake 

The brake Is used to lock each joint In position when the servo motor Is turned off and Is necessary to 
keep the arm from collapsing. The brake Is much like a D.C. relay. When O.C. current passes through the coll 
(an electromagnet), the brake plate Is retracted from the friction plate allowing the motor to rotate. When no 
current Is flowing In the brake coll, the brake plate Is forced Into contact with the friction plate by 
compression springs and the motor cannot rotate. On the Unimate controller, the brake release current Is 
supplied whenever the 'arm power' Is on. This Is a fall-safe system. When the servo power (to the motors) Is 
turned on, the brakes are released. When the arm power Is switched off, the brakes are automatically applied, 
holding the joint In place. 

5*2.6 Other 1/0 Requl rements 

The Joint Interface Board must not only accommodate the joint motor signals but must also provide the host 
computer with additional functions to allow all subsystems to be integrated Into a complete controller. 

Included in the design are (1) a digital timer and associated Interrupt circuitry, and (2) 24 bits of general 
purpose I/O lines. 

5.3 Host Computer Requirements 

The selection of a suitable host computer Is very Important. The machine must not only be capable of 
meeting basic execution speed and I/O requirements, but should also be able to support the software tools needed 
to implement a controller. In this section both the host computer hardware and software are discussed. 

5.3.1 The Computer : Intel System 310 

The Intel System 310 microcomputer was used because it satisfies the above criteria. It Is based on the 
Intel 80286 16-bit microprocessor [4]; the system also comes equipped with an 80287 floating point math co- 
processor [5], It Is a Multibus based system [6], a bus standard which Is particularly popular In the area 
of Industrial automation. A wide variety of Interface board products. Including memory, I/O, and blank proto- 
type boards, are available from Intel and third party vendors. A standard Multibus board is comparatively large 
which allows complex circuits to fit onto a single board, allowing the use of a single bus Interface circuit. 

All the hardware for the Joint Interface Board was able to fit on a single board. 

5.3.2 The Operatl ng System Choice ; XENIX 286 

The Intel 310 can run several operating systems: the ubiquitous I8M PC's MS-DOS, the UNIX-like XENIX 

system O.S.. and the real-time, multi-tasking systems RMX-86 and RMX-286. 

XENIX was chosen to be the operating system of this project's Implementation. A substantial learning 
effort Is required to become proficient with an unfamiliar operating system and new software tools. XENIX 
minimizes this obstacle; many researchers are familiar with UNIX and need little time to master XENIX. Those 
unacquainted with UNIX can be motivated to learn XENIX since this knowledge Is useful on many other systems. 

This is a very important consideration on short term projects where learning a new operating system may require 
more time than the experiment itself. 

The XENIX operating system is Microsoft's licensed version of UNIX III with some of the Berkeley Software 
Distribution (BSD) enhancements (e.g. ' vl * and the C-shell), and several of their own enhancements. It Is a 
multi-user system. UNIX Is a very powerful environment for developing software and is widely used In the 
academic and research communities. The disadvantage is that it was not designed for real-time applications. 
Details of the techniques used to construct a real-time controller for our purpose are given later. 


6. The Design 

This section details the design and implementation of the above specifications. The discussion Is divided 
into three sections: (1) the hardware design of the Joint Interface Board (Jib); (2) the connection between the 

J.I.B. and the Unimate PUMA 560 controller; and (3) the software interface between the XENIX operating system 
and the JIB. 


6.1 Joint Interface Board Design 

The block diagram which outlines the J.I.o. hardware is shown In Figure 3. As seen from the computer side 
of the bus interface, the JIB Is a small collection of I/O devices: six 16-bit encoder counters; an encoder 

reset circuit; two PIO (parallel input/output) devices; timer and the interrupts reset logic. One of the PIOs 
is used exclusively to Interface to the ADC and DAC subsystem, and the other PIO is used for off-board digital 
expansion. 
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6.1.1 The Ana1og-D?g • tai Subsystem 

Communication and tontrol slnn-ls for ill seven OACs, the ADC and the analog multiplexer ar* ■■'■■■■ '•■1 to 
one of the PIOs '■ ; :y . '«i. rs. + l • Pi ) >*• In the Multibus address space and control of thes< > vices muse 

be made through tin; u r .; .a v s'-i ivf designing the system this way was bus speed considerations. 

The PIO, an 8255, can operate at J* * full 80286 bus speed while the ADCs and DACs are about twice as slow (450 
ns vs 180 ns). Rather than *’ow the bus lown on this board and degrade performance of the other onboard devices 
(e.g. the encoders), the ADC: and DACs ire given their own private slow bus. 

6.1.2 Analog Output ; The DACs 

Six analog voltage outputs are necessary to drive the basic joint servo motors. An additional analog 
voltage output was Included to permit future expansion, possibly the control of a more sophisticated gripper. 

To produce these outputs, seven Independent DACs (digital to analog converters) were used. The Independent DAC 
approach offers the advantaye of a very straightforward interface. Improved accuracy and simpler circuit design. 

As described in the Analysis section above, the analog outputs must be capable of delivering a voltage from 
-10 volts to +10 volts at a resolution of 10 bits (1 part In 1024) to properly drive the inputs of the servo 
motor power amplifier. 

6.1.3 Analog Input : The ADCs 

As described In the analysis section, each of the PUMA 560 joint motors has a potentiometer which produces 
an output from 0 to 5 volts and, to be useful In absolute position determination, these signals must be resolved 
to an 8-bit accuracy. Fast, high resolution analog to digital converters can be obtained at reasonable prices 
which exceed the basic specification but give the Joint Interface Board more power. Analog Devices' AD574 [7] 

Is a popular example. It has a 12-bit resolution, a conversion speed of less than 30 micro-seconds, selectable 
Input ranges of 0 to +10, 0 to +20, -5 to +5, and -10 to +10 volts, and a cost of less than $35. At this speed 
of conversion, one device is fast enough to convert all six joints' pot data in less than 0.2 milliseconds, a 
speed fast enough to allow the pots alone to be used as the primary feedback element in situations where It may 
be useful. 

To use one ADC to convert several analog input signals requires the use of an analog selector or multi- 
plexer. A typical analog multiplexer, the LF 1308 has eight voltage Inputs which are selected to one output. 

This output can then be converted by the ADC, one at a time. Like the DAC outputs, ADC outputs must also be 
latched. However, since the ADC output Is digital. It may be easily stored Inside the computer using software 
without using any special hardware. 

6.1.4 T Imer Subsystem 

Generating a constant sampling interval requires an external clock source to interrupt the CPU and cause 
the control software to execute. The Multibus provides a 10 MHz clock requiring an onboard frequency divider 
logic. To allow convenient changing of the sampling rate, a di vlde-by-ten prescaler followed by a micro- 
processor compatible programmable timer was selected. An Intel 18254 triple 16-bit timer I.C. [8] was used. It 
features extensive programmability, high resolution (one part in 65K). In the divide-by-n mode it can be 
programmed to generate a square wave with a period from 2 microseconds to 65 milliseconds in 1-microsecond 
steps. This corresponds to a rate from 22 Hz to 500 KHz (though rates above 200 Hz are not usable in the 

present system). Timer #0 is used as the interrupt clock, leaving timers #1 and #2 available for- future 

applicatl ons. 

6.1.5 Digital I/O 

To make the Joint Interface Board a more flexible and general purpose interface, an additional parallel 
input/output (PIO) I.C. was included in the design. All the 24 outputs from this device go directly off-board 
via the connector J12 and are not used by any of the ontJoard electronics. 

6.1.6 The Encoder Subsystem 

The JIB accepts six sets of incremental encoder signals. Each input set is used to control its own 16-bit 
counter, instructing it to count UP, count DOWN, do nothing, or RESET to zero. The encoder subsystem can be 

divided Into three parts: (1) the basic up-down counter; (2) the decode logic; and (3) the reset logic. 

A. The Counters 

The 16-bit up-down counter is a straightforward cascading of four 4-bit up-down synchronous counter 
with three control inputs: clock enable (CE), up-down select (UD), and reset (R). The system clock is 

running continuously at 1 MKz. 

To directly implement a state decoder, six decoders would have to be constructed. This would probably 
require six 16-pin DIP packages. These would probably have to be either bipolar PROM (programmable read 
only memory) or some type of PLA (programmable logic array). If the PROM approach is used, a 16 x 2 = 
32-bit PROM would be sufficient. The total number of bits required by all six units in this scheme is 196 
bits. 

This new 12-bit vector has 4096 possible states, each of which must be decoded to generate a 6-bit 
output vector, £, with the proper CE and UD signals for three counters. 
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For six counters, a total of 4096 x 6 x 2 * 48 K-bits is required. This is two orders of magnitude 
greater than the scheme where each counter has Its own state decoder. The advantage of this bit wasteful 
approach is that all this decoding can be done using just two 8 K-byte EPROMs packaged in 28-pin DIPs. 

These memory I.C.s are inexpensive and EPROM programmers are typically found in microprocessor development 
laboratories. 

B. The Encoder Reset System 

An index pulse signal is generated every incremental encoder (servo motor) rotation. This signal is 
used to supply quasi absolute position information about the motor so that the motor revolutions (e.g. 0°, 
360°, 720°, etc.) can be distinguished from one another. Typically these Index signals are only used 
during initialization of the hardware and software after system power up. Once the system has been 
initialized, incremental information alone is sufficient to determine absolute position (provided no 
encoder state changes are missed). 

The basic scheme of the reset/cal ibrate routine is to rotate each motor until the index pulse is found 
and then this position is defined to be the position zero. Conceivably, this could be done in software by 
continuously reading the index signal until it is detected. This would require the software to sample the 
signal fast enough so that the pulse is not missed when the motor is moving at some speed. 

To overcome this limitation, a hardware scheme was devised which allows calibration of the system with 
the motor to be running at any speed within its operating limits. Each counter has a synchronous reset 
input. The index signal from the encoder could be connected to this input causing the particular counter 
to reset to zero whenever the index pulse occurs. However, since the motor typically rotates tens of times 
during the joint travel, some form of selectively gating the index signal on and off was required. 

This circuit is asynchronously set or 'armed' via the ARM RESET signal. Once armed, the next 
occurrence of the index pulse generates a single reset pulse for the associated counter circuit. Once the 
reset pulse is issued, the circuit disarms Itself so that further occurrences of the index pulse will not 
reset the counters. The software can monitor these signals to check if the reset circuit is armed or not 
and can thereby determine if the index pulse has occurred. 

6.1.7 The- Mul ti-8us Interface 
— « 

Up to this point, all the subsystems described here have been computer independent (except for the general 
requirement of a 16-bit bus). This allows easy conversion to many other 16-bit computers such as the I8M-AT. 

At this point the design becomes specific to the hardware of the host machine. The Intel 310 system is based on 
the Multibus. The Multibus supports direct addressability up to one megabyte through a 20-bit address and 8- 
and 16-bit data transfers at a rate of five million transfers per second (10 M8/sec). The Joint Interface Board 
has been designed as a simple slave and never controls the Multibus. The JIB only decodes the address li r es and 
acts upon the command signals from the bus master. 

6.2 The Unimation Interface 

The following sections describe how the Joint Interface Board and the XENIX software interface running on 
the Intel 310 were connected to the Unimate PUMA 560 arm. Position feedback signals from the arm servo motors 
are sent to the JIB, and the JIB sends analog voltage outputs to the power amplifier, which in turn drives the 
servo motor in each joint. 

The Unimate PUMA controller consists of an LSI-11/73, six 6503-based joint controller boards, several low 
level interface boards, and a six channel-high current power amplifier. The controller presented in this 
project makes use of only the power amplifiers and one of the. feedback signal conditioning circuits. The LSI-11 
and the six microprocessor joint controllers are completely bypassed. 

To close the loop around the joint motors, the feedback signals from the PUMA 560 have to be connected to 
the Intel system and the output command voltages must be returned from the Intel to the power amplifiers -n the 
Unimate controller. It was considered desirable to make the necessary modification to the Unimate contrcl’er in 
such a way that switching between the Intel controller and the internal Unimate controller systems is as simple 
and safe as possible. 

Connecting the feedback signals from the Unimate Control 1 er to the Joint Interface Board is accomplished by 
inserting a proto-typing card (from here on called the Unimate Interface Board) into one of the several a. ail- 
able empty, unwired slots of the joint control 1 er porti on of the Unimate card cage [9]. This technique was 
selected for several reasons. All of the PUMA arm feedback signals enter the controller through connecter j-jO 
and are hard-wired directly to the ARM CABLE CARD in the card cage. Here some basic signal conditioning :s 
performed, power is supplied to the joint pots and encoders, and the encoder outputs are then buffered to 
produce clean logic levels. Since these functions are required ^nd. would have to be duplicated if this sub- 
system was not used, it was convenient to use the external hardware' and obtain these signals after conditioning. 

The only place these feedback signals are found is on the backplane of the PUMA joint controller’s card- 
cage. One of the available slots was chosen and all the necessary connections were made only by adding wires to 
the backplane, bringing all the feedback signals to the selected slot. This has the attractive feature cf not 
having to break or cut any Unimate connections, leaving the controller intact. When the Unimation Interface 
Card is removed frem its slot, the system is electrically and logically in its original condition. The card 
whicn is inserted into this slot also contains an inverting line driver to buffer the encoder signal to drive 
the wires connecting it to the Intel/JIB system. 


While the feedback signals can be sensed without breaking any connections in thp Unimate controller, this 
is not possible for the motor current command signals. In general, either the Ummate or the Intel/JIB joint 
motor current command signals (the DAC outputs) can be used, since only one controller can be selected to drive 
any motor at any one time. Current command signals enter the power amplifier through connectors P73 and P/4. 
These connectors are located on the top of the POWER AMP CONTROL card and are readily detached. This is the 
only point where these signals can be 'intercepted* and the Intel signals injected without permanently modifying 
the circuit (e.g. cutting wires). A small interface panel w.th the appropriate connectors was fabricated to 
allow the JIB and Unimate motor current commanj signals to be selectively sent to the Ummate’ s power amplifier 
on a joint-by-joint basis (whic.h s very useful during system debugging). 

6 . 3 The XENIX to the Joi n t Cont rol ler Boa rd Inte rface 

The Joint Interface Board is installed in the I/O space of the Intel 310 (distinct from the memory space) 
and like all other system hardware in XENIX, the user can only access it through system device drivers. Drivers 
for all the JIB devices have been written and installed into XENIX (see software listing in Appendix H [I]). 
Application programs access these devices through symbolic names (e.g. “dac 1", "adc_4“, "timer_r*, etc.). The 
device driver controls the details of the data format and of physically addressing the hardware transparent to 
the application program [10]. 

Properly written drivers protect the system from the application programs and make the user interface 
clean and simple. A motor controller can be implemented entirely at the application levpl , individually access- 
ing the incremental encoders. UACs and the ADC through their respective device drivers. While this will work, 
much of the CPU time is consumed in operating system overhead. Each I/O request (e.g, read and write) takes 
Substantial ly longer to execu..- than if the software is able to directly address the hardware (not permitted in 
XENIX). An alternative to implementing the controller at the application level is to place it in the XENIX 
kernel as a single logical cevice (e.g. rather than "dac l" and “encd 1" devices, a single "pid 1“ can be 
considered as the basic I/O unit). Code written at the Fernet level Has direct access to the I/O space and may 
read and write to the JIB without going through the operating system. This reduction of overhead can reduce 
execution time by about 50-. 

6.4 Real-Time Issues 

XENIX is not a real-time operating system; it does not guarantee when a particular application program will 
get executed. It is often said that XENIX (vis-a-vis UNIX) does not guarantee when an interrupt is serviced. 

This only refers to the application levei. not the lowest level of interrupt handling. In the common applica- 
tion of a terminal handler, an interrupt is issued from the serial interface hardware (a UART) each time a rew 
character is received from the terminal. The interrupt handling software then services the hardware, taking the 
new character and putting it into the terminal handler's buffer. This software only competes with other 
interrupt routines (e.g. otner terminals) for CPU time. Non- i nterrupt level operating system software which 
processes the characters in the terminal handler’s buffer must compete with the entire system (includinc other 
application programs) for CPU time and it is here where XENIX cannot guarante'e response time. This issj.* is 
important in designing a real-time controller. 

A XENIX based real-time controller may be constructed in two fundamentally different ways. Roth methods 
require tnat an external timer interrupt the CPU at fixed intervals and that kernpl level device driver be 
installed in the XENIX system to process this interrupt. In the first method, the interrupt handler of the 
driver responds to the tinier interrupt by only setting a flag in the driver's memory. When the 'device' is read 
by the application software, the read part of the driver tests this memory flag. If the flag is set, it returns 
bar> to the application program. If the flag has not been set (i.e. the timer has not yet interrupted the CPU), 
rn f . read routine »eeps testing tne flag until it is set by tne timer interrupt. This technique allows 
application programs to synchronize themselves to the external clock and produce a constant sampling rate for a 
digital controller written at this level. However, XENIX does not. guarantee when the application program will 
be allowed to execute, and this may lead to occasional missed sampling intervals. As long as XENIX is run in 
the single user node and the timer interrupt is not faster than 100 Hz, a useful system can be implemented. 

; n *he second method, the one used in tn i s project, tne entire control system software is installed at the 
• erne! level of 'EM* and is executed as part of tne interrupt service routine of the driver itself. Since the 
interrupt service routine dues not nave to compete with the non- i nterrupt portion of XENIX (including all 
application programs), tms technique is guaranteed to. be executed on each timer interrupt, producing a reliable 
s amp 1 i eg interval. 

r n i $ is an effective method of implementing a real-time controller in XENIX. There are d i sadvantages to 
havin'; me controller at the device driver level, however, first is software development time. Drivers must be 
physically imred to the r E N I x xernel . This' takes about 15 minutes and substantial ly increases thp development 
fine fric the 'ortroller code, Secondly, since device drivers nave full access to the syst em , prog r a mm ing errors 
may destroy the software system • requiring XENIX to be reloaded from diskette). In spite of these problems, 
this still seems to be fni* moSft' practical way of building .1 controller in XENIX. - * . ■■ 

/ . A[ij. ! i r a f. i on and lone i us l on 

Are, 1 leafier 

dree the hint Interface Hoard was constructed and debugged , the basic i/0 drivers were installed into thp 
i i •, r , s.sfe'- .im! tested. After 'he basic, system became operational , a simple hut complete example of a 

■ n f r ■ : 1 1 . ■ r *dS :e- jqr.ed and tested. 
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The objective of this project was to design and construct the hardware and Interface 
a robot controller. To perfoni a functional test on the entire system, a simple six-axis P.0, digital control- 
ler was implex . ted. In addition to testing the Integrated system, it also served as a documented application 
guide for use of the JIB and the XENIX interface. 

Fiuure 4 shows the basic controller system. The controller is divided into five distirKt subsystems: 

(1) the 9 application software which Issues high level joint motion canmands (kinematics, path planning, etc.) and 
runs tn the normal application environment of XENIX; (2) kernel level driver software wh ch interprets the read 
and write commands from the application programs; (3) interrupt level driver software w ^ ch the 

interrupt by executing the control structure software, reading and writing directly to the JIB ** rd "* re ; 

Joint Interface Board which Interfaces the computer joint motor signals; and (6) the robot arm itself, including 
power amplifiers, joint motors and feedback elements. 

The simple P.D. controller implemented in this project was able to satisfactorily control all six PDHA 560 
joint motors simultaneously. The P.D. coefficients were experimentally determined by trial and error. This was 

nnp mint at a time while the other joints were locked. When all joints were operated together, the strong 
Coupling between joints 2 and 3 ^Shoulder and elbow) caused strong oscillations. The gat ns of these jol nts^were 
reduced to produce a more stable system. This Is an area where more sophisticated control techniques should 
produce improved results. 

7.2 Conclusion 

The basic objective of designing and constructing a general purpose robotic control 1 er was completed 
successful ly The system has been used to control the PUMA 560 robot arms, demonstrating the functionality and 
flexibility of the design. The Joint Interface Board has served its overall design objective well. 

Using the XENIX operating system was done with mixed results. High level software is easi ly deve! ope- d (at 
least for UNIX users). Whereas the method of low-level servo-loop software Programming was so*ewhat ’ « S rn ^ a " 
desirable in that routines on this level must be directly linked (using the Id linked) to the XENIX kernel. 
Therefore it involves a fairly time-consuming task. XENIX also prohibits wri ti ng C-code in the kernel eve 
which uses the floating point coprocessor (via an undocumented c-compiler flag). This was disappointing, hut 
there are ways around this problem. This last issue is an area where more time and effort would be useful. 
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